-
Notifications
You must be signed in to change notification settings - Fork 41.2k
'spring.resources.cache.period' is always overridden by 'spring.resources.cache.cachecontrol' #16730
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Concourse seems to have issues pulling the docker image :( About the code, once it gets merged onto master the tests needs to be guarded by Similar to this PR where it was done to the WebFluxAutoconfigurationTests.class a2c5a79 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the light of this PR, I think we should close the related issue and fix this at the Framework level.
We should keep this PR to fix the test once the issue is resolved in Framework.
CacheControl cacheControl = this.resourceProperties.getCache() | ||
ResourceProperties.Cache.Cachecontrol cacheControl = this.resourceProperties | ||
.getCache().getCachecontrol(); | ||
if (cachePeriod != null && cacheControl.getMaxAge() == null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cachePeriod
is not only about max-age; if cachePeriod=-1
nothing is done, 0
means a no-store
configuration, a positive number results in a max-age configuration. But this should delegate to Spring Framework and not hardcode those assumptions here.
A short term solution would be to check whether CacheControl.getHeaderValue()
is not null
and only apply it in this case. A better solution IMO would be to create a Spring Framework issue and getting this solved at the Framework level (see first comment in #16488).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your review, really sounds reasonable 👍
I think we just need to keep in mind that Webflux has basically the same implementation and when resolved it should also getting fixed there. See: https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/web/reactive/WebFluxAutoConfiguration.java#L169-L177
Before this change it got overwritten by forwarding an empty CacheControl to Spring. Spring itself sets CacheSeconds already correctly in absence (=null) of a CacheControl. Also: * Fixes bug in WebMvcAutoConfigurationTests.cachePeriod which prevented it to assert anything See: #16488
@bclozel maybe you want to have another look. I documented my findings in #16488 Not sure what is up with concourse 😓 the follow up build triggered by my update on the branch is waiting for 'checking max-in-flight is not reached' because of the earlier build. (PS: it worked on my machine before pushing it) Edit: After the first build timed out, the second one built flawlessly 🤷♂ |
* pr/16730: Fix 'spring.resources.cache.period' for WebMvc
Before this change it got overwritten by forwarding an empty
CacheControl to Spring. Spring itself sets CacheSeconds already
correctly in absence (=null) of a CacheControl.
Also:
See: #16488